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Localized Routing for Proxy Mobile IPv6 


Abstract 


Proxy Mobile IPv6 (PMIPv6) is a network based mobility management 
protocol that enables IP mobility for a host without requiring its 
participation in any mobility-related signaling.  PMIPv6 requires all 
communications to go through the local mobility anchor. As this can 
be suboptimal, Localized Routing (LR) allows Mobile Nodes (MNs) 
attached to the same or different Mobile Access Gateways (MAGs) to 
route traffic by using localized forwarding or a direct tunnel 


between the gateways. This document proposes initiation, 
utilization, and termination mechanisms for localized routing between 
mobile access gateways within a proxy mobile IPv6 domain. It defines 


two new signaling messages, Localized Routing Initiation (LRI) and 
Local Routing Acknowledgment (LRA), that are used to realize this 
mechanism. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by 

the Internet Engineering Steering Group (IESG). Further 
information on Internet Standards is available in Section 2 of 

RFC 5741. 


Information about the current status of this document, any 
errata, and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6705. 
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document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
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Les 


Introduction 


Proxy Mobile IPv6 [RFC5213] describes the protocol operations to 
maintain reachability and session persistence for a Mobile Node (MN) 
without the explicit participation from the MN in signaling 
operations at the Internet Protocol (IP) layer. In order to 
facilitate such network-based mobility, the PMIPv6 protocol defines a 
Mobile Access Gateway (MAG), which acts as a proxy for the Mobile 
IPv6 [RFC6275] signaling, and the Local Mobility Anchor (LMA), which 
acts similar to a Home Agent. The LMA and the MAG establish a 
bidirectional tunnel for forwarding all data traffic belonging to the 
Mobile Nodes. In the case where both endpoints are located in the 
same PMIPv6 domain, this can be suboptimal and result in increased 
delay and congestion in the network. Moreover, it increases 
transport costs and traffic load at the LMA. 


To overcome these issues, localized routing can be used to allow 
nodes attached to the same or different MAGs to directly exchange 
traffic by using localized forwarding or a direct tunnel between the 
gateways. [RFC6279] defines the problem statement for PMIPv6 
localized routing. This document describes a solution for PMIPv6 
localized routing between two MNs in the same PMIPv6 domain. The 
protocol specified here assumes that each MN is attached to a MAG and 
that each MN's MAG has established a binding for the attached MN at 
its selected LMA according to [RFC5213]. The protocol builds on the 
Scenarios defined in [RFC6279]. 


Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


This document also uses the terminology defined in Section 2 of 
[RFC6279]. 


Initiation of Localized Routing 


Since the traffic to be localized passes through both the LMA and the 
MAGs, it is possible, at least in some scenarios, for either of them 
to initiate Localized Routing (LR). In order to eliminate ambiguity, 
the protocol described in this document selects the initiator of LR 
based on the rules below. 
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3.1. MAG Behavior 


The MAG MUST initiate LR if both of the communicating MNs are 
attached to it and the MNs are anchored at different LMAs. The MAG 
MUST NOT initiate LR in any other case. 


3.2. LMA Behavior 


The LMA MUST initiate LR if both of the communicating MNs are 
anchored to it. The LMA MUST NOT initiate LR in any other case. 


4.  Teardown of Localized Routing 


The use of localized routing is not persistent.  Localized routing 
has a defined lifetime as specified by the initiator; upon expiry, 
the forwarding MUST revert to using bidirectional tunneling. When 
localized routing ceases, the corresponding Localized Routing Entries 
(LREs) MUST be removed. 


If the initiator of LR wishes to terminate localized routing before 
the expiry of the lifetime specified in the LRI message, it MUST do 
SO by sending a new LRI message with the lifetime set to zero. 

5. Scenario All: Two MNs Attached to the Same MAG and LMA 
In this scenario, the two Mobile Nodes involved in communication are 
attached to a single MAG and both are anchored at the same LMA as 


shown in Figure 1. 


Internet 


denos dcs 
|MN1| |MN2| 
+---+ +---+ 


Figure 1 
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The LMA initiates a localized routing session by detecting traffic 
between two MNs attached to the same MAG. 
identification mechanism is not specified in this document and is 


left open for implementations and specific deployments. 


The exact traffic 


An example 


trigger could be that an application-layer signaling entity detects 
the possibility of localized routing and notifies the LMA about the 
and the LMA determines that the two endpoints are 


two endpoints, 
attached to the same MAG. 
routing at the granularity of an individual 
providing flexibility in usage. 
LMA or MAG) could decide 


mobility entities ( 


routing based on configured policy. 
implementing the protocol specified in this 
dynamically initiate LR in the same LMA case 


It is also 


Please 


Such a trigger mechanism offers localized 


application session, 
possible that one of the 
to initiate localized 
note that a MAG 

document will not 


LRI), but can statically initiate LR based on the 
EnableMAGLocalRouting configuration variable specified in [RFC5213]. 


++ T----- ++ 
|MN1 | |MN2 | |MAG1 | 
+----+ +----+ +----+ 
| | | 
data data 
«--------------------- > | <----------- 
| | | 
| | data | data 
| [e > |<----------- 
| | | 
LRI (Opt1) 
| E 
| | | 
| | | LRA(Opt2) 
| | | 
| | | 
data 
«--------------------- > 
data 


Opt1: MN1-ID,MN1-HNP,MN2-ID,MN2-HNP 


Opt2: U=0,MN1-ID,MN1-HNP,MN2-ID,MN2-HNP 


+----+ 
[IMA | 
+----+ 

| 
--> 

| 

| 


LR decision 


where U is the flag defined in Section 10.2. 
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by sending an 
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After detecting a possibility for localized routing, the LMA SHOULD 
construct an LRI message that is used to signal the intent to 
initiate localized routing and to convey parameters for the same. 
This is a Mobility Header message and it MUST contain the MN- 
Identifier (MN-ID) and the Home Network Prefix (HNP) (as Mobility 
Header options) for each of the MNs involved. The LMA MUST then send 
the LRI message to the MAG (MAG1) where the two MNs are attached. 

The initiation of the LR procedure is shown in Figure 2. 


The MAG (MAG1) MUST verify the attachment status of the two MNs 
locally by checking the binding cache. The MAG MUST then verify if 
the EnableMAGLocalRouting flag is set to 1. If it is not, the MAG 
has not been configured to allow localized routing, and it MUST 
reject the LRI and MUST send an LRA with Status code "Localized 
Routing Not Allowed". Please note that this does not update behavior 
specified in [RFC5213] but merely implements the LMA enforcement 
specified in Section 6.10.3 of [RFC5213]. If the MAG is configured 
to allow localized routing, it MUST then create LREs for each 
direction of the communication between the two MNs. The exact form 
of the forwarding entries is left for the implementations to decide; 
however, they SHOULD contain the HNP corresponding to the destination 
IP address and a next-hop identifier (e.g., the layer-2 address of 
the next hop). These LREs MUST override the Binding Update List 

(BUL) entries for the specific HNPs identified in the LRI message. 
Hence, all traffic matching the HNPs is forwarded locally. 


If the MAG is unable to deliver packets using the LREs, it is 
possible that one of the MNs is no longer attached to the MAG. 
Hence, the MAG MUST fall back to using the BUL entry, and the LMA 
MUST forward the received packets using its Binding Cache Entry 
(BCE). 


After processing the LRI message, the MAG MUST respond with a Local 
Routing Acknowledgment (LRA) message. This Mobility Header message 
MUST also include the MN-ID and the HNP for each of the communicating 
MNs, as well as an appropriate Status code indicating the outcome of 
LRI processing. Status code 0 indicates localized routing was 
successfully offered by the MAG. Any other value for Status code 
indicates the reason for the failure to offer localized routing 
service. When Status code is 0, the LMA sets a flag in the BCE 
corresponding to the HNPs to record that localized routing is in 
progress for that HNP. 


5.1. Handover Considerations 
If one of the MNs, say MN1, detaches from the MAG and attaches to 


another MAG (say nMAG), the localized routing state needs to be 
re-established. When the LMA receives the PBU from nMAG for MN1, it 
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will see that localized routing is active for MN1. The LMA MUST 
hence initiate LR at nMAG and update the LR state of pMAG. After the 
handover completes, LR will resemble Scenario A21. The pMAG MUST 
follow the forwarding rules described in Section 6.10.5 of [RFC5213] 
and decide that it will no longer perform LR for MN1. 


6. Scenario A21: Two MNs Attached to Different MAGs but the Same LMA 


The LMA may choose to support local forwarding to Mobile Nodes 
attached to two different MAGs within a single PMIPv6 domain. 


Internet 
| 
| 
4----- * 
| IMA | 
4----- * 
| 
| 
4+----+----- + 
| | 
+----+ +----+ 
| MAG1 | | MAG2 | 
4----—4 *----—4 
+---+ +---+ 
| MN1 | | MN2 | 
+---+ +---+ 
Figure 3 


As earlier, the LMA initiates LR as a response to some trigger 
mechanism. In this case, however, it MUST send two separate LRI 
messages to the two MAGs. In addition to the MN-ID and the HNP 
options, each LRI message MUST contain the IP address of the 
counterpart MAG. When the MAG IP address option is present, each MAG 
MUST create a local forwarding entry such that the packets for the MN 
attached to the remote MAG are sent over a tunnel associated with 
that remote MAG. The tunnel between the MAGs is assumed to be 
established following the considerations mentioned in Section 6.2. 
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4+----+ 4+----+ 4+----+ 4+----+ 4+----+ 
|MN1 | |MN2 | | MAG1 | | MAG2 | |LMA | 
4+----+ 4+----+ 4+----+ 4+----+ 4+----+ 
| | | | | 
data data 
| | | 
| <--------------------- > | <----------------------- > | 
| | | | | 
| | data | data | 
| <--------------------- »|«----------- > 
| 
| | | | | 
| | | LRI (Opt1) 
| | | <-------==--"-==--------- | 
| | | | | 
| | | | LRI(Opt2) | 
| | | ~ | 
| | | LRA (Opt 3) | 
| | |------------------------ >| 
| | | | | 
| | | | | LRA(Opt4) | 
| | | p eno 
| | | | | 
| | | | | 
ata ata 
| dat | dat | | 
|<--------------------- >|<--------- >| | 
| 
| data 
| | | 
| | | 
| | | 


Opti: MN1-ID,MN1-HNP,MAG2-IPv6-Address 
Opt2: MN2-ID,MN2-HNP,MAG1-IPv6-Address 
Opt3: U=0,MN1-ID,MN1-HNP,MAG2-IPv6-Address 
Opt4: U=0,MN2-ID,MN2-HNP,MAG1-IPv6-Address 


where U is the flag defined in Section 10.2. 
Figure 4 
In this case, each MAG responds to the LRI with an LRA message. All 
subsequent packets are routed between the MAGs locally, without 


traversing the LMA. If one of the MAGs (say MAG1) responds with a 
successful LRA (Status value is zero) and the other (say MAG2) 
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responds with an error (Status value is non-zero), LR will still be 
performed in one direction (MN1->MAG1->MAG2->MN2), but the packets 
flowing the other way will take the LMA path 
(MN2-—>MAG2->LMA->MAG1->MN1) . 


The protocol does not require any synchronization between the MAGs 
before local forwarding begins. Each MAG begins its local forwarding 
independent of the other. 


No synchronization between the MAGs is required because each MAG 
initiates LR in one direction. After the LMA instructs MAG1 to 
initiate LR, packets from MN1 to MN2 will take the path 
MN1->MAG1->MAG2->MN2 while those from MN2 to MN1 will take the path 
MN2->MAG2->LMA->MAG1->MN1 until the LMA instructs MAG2 to initiate LR 
as well. A MAG will forward a packet towards either another MAG or 
its own LMA; therefore, there would be no duplication of packets. 


6.1. Handover Considerations 
If one of the MNs, say MN1, detaches from its current MAG (in this 
case MAG1) and attaches to another MAG (say nMAG1), the localized 
routing state needs to be re-established. When the LMA receives the 
PBU from nMAG1 for MN1, it will see that localized routing is active 
for MN1. The LMA MUST then initiate LR at nMAG1 and update the LR 
state of MAG2 to use nMAG1 instead of MAG1. 

6.2.  Tunneling between the MAGs 
In order to support localized routing, both MAGs SHOULD support the 
following encapsulation modes for the user packets, which are also 
defined for the tunnel between the LMA and MAG: 
o IPv4-or-IPv6-over-IPv6 [RFC5844] 
o IPv4-or-IPv6-over-IPv4 [RFC5844] 
o IPv4-or-IPv6-over-IPv4-UDP [RFC5844] 
o TLV-header UDP tunneling [RFC5845] 


o Generic Routing Encapsulation (GRE) tunneling with or without GRE 
key (s) [RFC5845] 


MAG1 and MAG2 MUST use the same tunneling mechanism for the data 


traffic tunneled between them. The encapsulation mode to be employed 
SHOULD be configurable. It is RECOMMENDED that: 
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1. As the default behavior, the inter-MAG tunnel uses the same 
encapsulation mechanism as that being used for the PMIPv6 tunnel 
between the LMA and the MAGs.  MAG1 and MAG2 automatically start 
using the same encapsulation mechanism without a need for a 
special configuration on the MAGs or a dynamic tunneling 
mechanism negotiation between them. 


2. Configuration on the MAGs can override the default mechanism 
specified in Option 1 above. MAG1 and MAG2 MUST be configured 
with the same mechanism, and this configuration is most likely to 
be uniform throughout the PMIPv6 domain. If the packets on the 
PMIPv6 tunnel cannot be uniquely mapped onto the configured 
inter-MAG tunnel, this scenario is not applicable, and Option 3 
below SHOULD directly be applied. 


3. An implicit or explicit tunnel negotiation mechanism between the 
MAGs can override the default mechanism specified in Option 1 
above. The employed tunnel negotiation mechanism is outside the 
Scope of this document. 


7. Scenario A12: Two MNs Attached to the Same MAG with Different LMAs 


In this scenario, both the MNs are attached to the same MAG, but are 
anchored at two different LMAs. MN1 is anchored at LMA1, and MN2 is 
anchored at LMA2. Note that the two LMAs are part of the same 
Provider Domain. 


Internet 
4------------------ + 
| | 
+----+ +----+ 
| LMA1 | | LMA2 | 
4----—4 +----+ 
4+------------------ + 
| 
| 
| 
4----- * 
| MAG | 
4----- * 


denos dcs 
|MN1| |MN2| 
4+---+ +---+ 


Figure 5 
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Hence, neither LMA has a means to determine that the two Mobile Nodes 
are attached to the same MAG. Only the MAG can possibly determine 
that the two Mobile Nodes involved in communication are attached to 
it. Therefore, localized routing MUST be initiated by the MAG. 


The MAG sends an LRI message containing the MN-ID, HNP, and the 
counterpart LMA address to each LMA. Each LMA makes a decision to 
support local forwarding independently based on configured policy for 
the corresponding LMA. Each LMA MUST respond to the LRI message with 
an LRA message. If the initiation of LR on the LMA was successful, 
the Status value in the received LRA would be set to zero. After the 
MAG receives both the LRA messages, each with the Status value set to 
zero (success) from the two different LMAs, the MAG will conclude 
that it can provide local forwarding support for the two Mobile 
Nodes. 
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+----+ +----+ +----+ +----+ +----+ 
|MN1 | |MN2 | |MAG | | LMA1 | | LMA2 | 
+----+ +----+ +----+ +----+ +----+ 

| | | | | 
| data | data | data | 
|<--------------------- >|<--------- >|<----------- >| 
| | | | | 
| | data | data | 
| «--------- > | <----------------------- > 
| 
| | | | | 
| | | LRI(Opt1) | | 
| | [Sesa >| | 
| | | | | 
| | | LRI (Opt2) | 
| | PNE MEE 
| 
| | | LRA(Opt3) | | 
| | | | | 
| | | | | 
| | | LRA (Opt 4) | 
| | ee eis | 
| 
| | | | | 
| | | | | 
| data | | | 
e E > | | | 
| | data | | 
| AE >| | | 
| | | | | 
| | | | | 
Opt1: MN1-ID,MN1-HNP 
Opt2: MN2-ID,MN2-HNP 
Opt3: U=0,MN1-ID,MN1-HNP 
Opt4: U=0,MN2-ID,MN2-HNP 


where U is the flag defined in Section 10.2. 


If one of the MNs, 
) and attaches to another MAG 


case MAG1 


Handover Considerations 


say MN1, 


Figure 6 


detaches from its current MAG 


(say nMAG1), 


(in this 
the current MAG 


MUST immediately stop using the LRE and MUST send all packets 


originate 


Krishnan, et 


d by the other MN 


al. 


(MN2) 


towards its LMA 


Standards Track 


(in this case LMA2). 
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8. Scenario A22: Two MNs Attached to Different MAGs with Different LMAs 


This scenario will not be covered in this document since PMIPv6 does 
not define any form of inter-LMA communication. When a supported 
Scenario, such as Scenario A12, morphs into Scenario A22, the node 
that initiated the localized routing session MUST tear it down in 
order to prevent lasting packet loss. This can result in transient 
packet loss when routing switches between the localized path into the 
normal path through the LMAs. In applications that are loss 
sensitive, this can lead to observable service disruptions. In 
deployments where Scenario A22 is possible, the use of localized 
routing is NOT RECOMMENDED when packet-loss-sensitive applications 
are in use. 


9. IPv4 Support in Localized Routing 


PMIPv6 MNs can use an IPv4 Home Address (HoA) as described in 
[RFC5844]. In order to support the setup and maintenance of 
localized routes for these IPv4 HoAs in PMIPv6, the MAGs MUST add the 
IPv4 HoAs into their LREs. The MAGs MUST also support encapsulation 
of IPv4 packets as described in [RFC5844]. The localized routing 
protocol messages MUST include an IPv4 HoA option in their signaling 
messages in order to support IPv4 addresses for localized routing. 


If the transport network between the PMIPv6 entities involved in 
localized routing is IPv4-only, the LRI and LRA messages MUST be 
encapsulated similar to the PBU/PBA messages as specified in 
[RFC5844]. The encapsulation mode used SHOULD be identical to the 
one used to transport PBU and PBA messages. 


10. Message Formats 
The localized routing messages use two new Mobility Header types (17 
and 18). The LRI message requests creation or deletion of the 


localized routing state, and the LRA message acknowledges the 
creation or deletion of such localized routing state. 
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10. 


1.  Localized Routing Initiation (LRI) 


The LRI messages use a new Mobility Header type (17). The LMA sends 
an LRI message to a MAG to request local forwarding for a pair of 
MNs. The MAG may also send this message to request the two LMAs for 
offering local forwarding as described in Section 7. 


0 1 2 3 
01234567829 0123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Sequence # | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Reserved | Lifetime | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| | 


Mobility options 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Sequence Number: A monotonically increasing integer. Set by a 
sending node in a request message and used to match a reply to the 
request. 


Reserved: This field is unused and MUST be set to zero. 


Lifetime: The requested time, in seconds, for which the sender 
wishes to have local forwarding. A value of Oxffff (all ones) 
indicates an infinite lifetime. When set to 0, indicates a 
request to stop localized routing. 


Mobility Options: MUST contain two separate MN-ID options, 
followed by one or more HNPs for each of the MNs. For instance, 
for Mobile Nodes MN1 and MN2 with identifiers MN1-ID and MN2-ID, 
and Home Network Prefixes MN1-HNP and MN2-HNP, the following tuple 
MUST be present in the following order: [MN1-ID, MN1-HNP], 

[MN2-ID, MN2-HNP]. The MN-ID and HNP options are the same as in 
[RFC5213]. The LRI MAY contain the remote MAG IPv6 address 
option, which is formatted identically to the HNP option, except 
that it uses a different Type code and the Prefix Length is always 
equal to 128 bits (see Section 10.1). 


The LRI message SHOULD be re-transmitted if a corresponding LRA 


message is not received within LRA WAIT TIME time units, up to a 
maximum of LRI RETRIES, each separated by LRA WAIT TIME time units. 
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10. 


Localized Routing Acknowledgment (LRA) 


The LRA messages use a new Mobility Header type (18). A MAG sends an 
LRA message to the LMA as a response to the LRI message. An LMA may 
also send this message to a MAG as a response to the LRI message as 
described in Section 7. 


0 1 2 3 
Ol E B94, SiO 8 O 1. 2 O A e e 0:172 3-4 5:6. 78.9 0-1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 
| Sequence # | 
dh A A A O O A O hh hh hh hh o o +++ 
|u| Reserved | Status | Lifetime 
dh A A A A O A O A TTL] hh o o +++ 
| | 


Mobility options 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Sequence Number: Copied from the sequence number field of the LRI 
message being responded to. 


'U' flag: When set to 1, the LRA message is sent unsolicited. 


The Lifetime field indicates a new requested value. The MAG MUST 
wait for the regular LRI message to confirm that the request is 
acceptable to the LMA. 


Reserved: This field is unused and MUST be set zero. 


Status: 8-bit unsigned integer indicating the result of 
processing the Localized Routing Acknowledgment message. Values 
of the Status field less than 128 indicate that the Localized 
Routing Acknowledgment was processed successfully by the mobility 
entities (LMA or MAG). Values greater than or equal to 128 
indicate that the Localized Routing Acknowledgment was rejected 
by the mobility entities. The following Status values are 
currently defined: 


0: Success 
128: Localized Routing Not Allowed 
129: MN Not Attached 


Lifetime: The time, in seconds, for which local forwarding is 
supported. It is typically copied from the corresponding field 
in the LRI message. 
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Ts 


11. 


Mobility Options: When Status code is 0, MUST contain the 
[MN-ID, HNP] tuples in the same order as in the LRI message. 
When Status code is not 0, MUST contain only those [MN-ID, HNP] 
tuples for which local forwarding is supported. The MN-ID and 
HNP options are the same as those described in [RFC5213]. 


New Mobility Option 


MAG IPv6 Address 


The MAG IPv6 address mobility option contains the IPv6 address of a 
MAG involved in localized routing. The MAG IPv6 address option has 
an alignment requirement of 8n+4. 


0 1 2 3 
0.1 2:294 5:6 789 9.012 345 6789 01.234 50 7 89€ 9-0.1 
*—4—4—4—4-4-t-t-t-----t-t-t-t-—t-—t-—t-—L- 4 ———4—4-4-4-4-4-4-4 
| Type | Length | Reserved | Address Length| 
T—4—4—4—4-—4-t-t-t------t-t-t-t-—t-—L-—L- 4 —4—4—4—4-4-4-4-4-4-4 


| | 
+ + 
| | 
+ MAG IPv6 Address + 
| | 
+ + 
| | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type 
51 
Length 
8-bit unsigned integer indicating the length of the option 
in octets, excluding the type and length fields. This field 
MUST be set to 18. 


Reserved (R) 


This 8-bit field is unused. The value MUST be initialized 
to 0 by the sender and MUST be ignored by the receiver. 


Address Length 


This field MUST be set to 128. 
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13. 


14. 


MAG IPv6 Address 
A 16-byte field containing the MAG's IPv6 address. 
Configuration Variables 


The LMA and the MAG must allow the following variables to be 
configurable: 


LRA WAIT TIME: This variable is used to set the time interval, in 
seconds, between successive retransmissions of an LRI message. 
The default value is 3 seconds. 


LRI RETRIES: This variable indicates the maximum number of times the 
initiator retransmits an LRI message before stopping. The default 
value for this variable is 3. 


Security Considerations 


The protocol inherits the threats to [RFC5213] that are identified in 
[RFC4832]. The protocol specified in this document uses the same 
security association as defined in [RFC5213] for use between the LMA 
and the MAG to protect the LRI and LRA messages. This document also 
assumes the preexistence of a MAG-MAG security association if LR 
needs to be supported between them. Support for integrity protection 
using IPsec is REQUIRED, but support for confidentiality is OPTIONAL. 
The MAGs MUST perform ingress filtering on the MN-sourced packets 
before encapsulating them into MAG-MAG tunnels in order to prevent 
address spoofing. 


IANA Considerations 


The Localized Routing Initiation (described in Section 10.1) and the 
Localized Routing Acknowledgment (described in Section 10.2) have 
each been assigned a Mobility Header type (17 and 18, respectively) 
from the "Mobility Header Types - for the MH Type field in the 
Mobility Header" registry at 
http://www.iana.org/assignments/mobility-parameters. 


The MAG IPv6 Address has been assigned a Mobility Option type (51) 
from the "Mobility Options" registry at 
http://www.iana.org/assignments/mobility-parameters. 
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16. 
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